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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document describes the Diameter based interface between the Machine Type Communications - 
InterWorking Function (MTC-IWF) and the Short Message Service-Service Centre (SMS-SC) for communications with 
packet data networks and applications. 

This specification defines the Diameter appHcation for the T4 reference point between the MTC-IWF and the SMS-SC. 
The interactions between the MTC-IWF and the SMS-SC are specified. 

The stage 2 description for communications with packet data networks and applications (architecture and functionality) 
is specified in the 3GPP TS 23.682 [2]. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

For a specific reference, subsequent revisions do not apply. 

For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 23.682: "Architecture enhancements to facilitate communications with packet data 

networks and applications". 

[3] IETF RFC 3588: "Diameter Base Protocol". 

[4] 3GPP TS 33.210: "3G Security; Network Domain Security; IP Network Layer Security". 

[5] IETF RFC 4960: "Stream Control Transmission Protocol". 

[6] 3GPP TS 29.229: "Cx and Dx interfaces based on the Diameter protocol". 

[7] 3GPP TS 29.228: "IP multimedia (IM) Subsystem Cx and Dx Interfaces; SignalHng flows and 

Message Elements". 

[8] 3GPP TS 23.003: "Numbering, addressing and idendfication". 

[9] 3GPP TS 23.040: "Technical reahzation of the Short Message Service (SMS)". 

[10] IETF RFC 5234: "Augmented BNF for Syntax Specifications: ABNF". 

[II] 3GPP TS 29.329: "Sh Interface based on the Diameter protocol". 

[12] 3GPP TS 29.336: "Home Subscriber Server (HSS) diameter interfaces for interworking with 

packet data networks and applications". 

[13] 3GPP TS 29.338: "Diameter based protocols to support SMS capable MMEs". 

[14] 3GPP TS 29.173: "Diameter-based SLh interface for Control Plane LCS". 

[15] 3GPP TS 29.368: "Tsp interface protocol between the MTC Interworking Function (MTC-IWF) 

and Service Capability Server (SCS)". 

[16] 3GPP TS 29.272: "Mobility Management Entity (MME) and Serving GPRS Support Node 

(SGSN) related interfaces based on Diameter protocol". 
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Definitions and Abbreviations 



3.1 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

ABNF Augmented Backus-Naur Form 

AVP Attribute-Value Pair 

C Conditional 

lANA Internet Assigned Numbers Authority 

MTC Machine-Type Communications 

MTC-IWF MTC Interworking Function 

O Optional 

SCS Service Capability Server 



General Description 



The T4 reference point between the MTC-IWF and the SMS-SC is an intra PLMN interface, as defined in the 3GPP TS 

23.682 [7]. 

This document describes the T4 interface related procedures, message parameters and protocol specifications. 

The T4 interface allows transfer of device trigger from MTC-IWF to SMS-SC inside HPLMN domain, along with the 
serving SGSN/MME/MSC identities, and allows SMS-SC to report to MTC-IWF the submission outcome of a device 
trigger and the success or failure of delivering the device trigger to the UE. 



MTC-IWF - SMS-SC (T4) 



5.1 Introduction 

This section describes the Diameter-based T4 interface related procedures and information elements exchanged between 
the MTC-IWF and the SMS-SC. 

In the tables that describe the Information Elements transported by each Diameter command, each Information Element 
is marked as (M) Mandatory, (C) Conditional or (O) Optional in the "Cat." column. For the correct handling of the 
Information Element according to the category type, see the description detailed in section 6 of the 3GPP TS 29.228 [7]. 



5.2 Procedure Descriptions 
5.2.1 Device Trigger Procedure 



5.2.1.1 General 

This procedure shall be used between the MTC-IWF and the SMS-SC for device trigger. The procedure shall be 
invoked by the MTC-IWF and is used: 

- to transfer device trigger to SMS-SC inside HPLMN domain; 

- to transfer to the SMS-SC the identities of the serving MSC or MME but not both, and/or SGSN, and/or IP-SM- 
GW serving the user for SMS along with device trigger. 

This procedure is mapped to the commands Device-Trigger-Request/Answer in the Diameter application specified in 
chapter 6. Tables 5.2.1.1/1 and 5.2.1.1/2 detail the involved information elements. 
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Table 5.2.1.1/1 : Device Trigger Request 



Information 
Element Name 


Mapping to 
Diameter AVP 


Cat. 


Description 


User Identifier 
(See 3GPP TS 
29.336 [12]) 


User-Identifier 


M 


This information element shall contain the IMSI of the UE the trigger is to 
be applied, formatted according to 3GPP TS 23.003 [8], clause 2.2. 
This Information Element may contain the international ISDN number of 
the UE the device trigger was delivered, formatted according to 3GPP TS 
23.003 [8], clause 3.3. The ISDN number shall be present if it is available 
to the MTC-IWF. 

This Information Element may contain the external identifier of the UE the 
device trigger was delivered, formatted according to 3GPP TS 23.003 [8], 
clause 19.7.2. The external identifier shall be present if it is available to the 
MTC-IWF. 


SM RP OA 
(See 3GPP TS 
29.336 [12]) 


SCS-ldentity 


M 


This Information Element shall contain the identity of the Service Capability 
Server that is requesting a device trigger to the UE. 


SMRPUI 
(See 3GPP TS 
29.338 [13]) 


SM-RP-UI 


M 


This information element shall contain short message transfer protocol 
data unit for device trigger. 


Serving Node 
Identity 

(See 3GPP TS 
29.173 [14]) 


Serving-Node 


C 


This information element shall contain the serving node identity, i.e. 
SGSN/MME/IVISC identity serving the UE. 

It shall be present if it is available to the MTC-IWF, e.g. the MTC-IWF 
retrieved this information from the HSS. 


Additional 
Serving Node 
Identity 

(See 3GPP TS 
29.173 [14]) 


Additional- 
Serving-Node 


C 


This information element shall contain another serving node identity, e.g. 
SGSN/MME/MSC identity, if there is any serving the UE. 
There may be multiple instances of this information elements. 


Trigger 
Reference 
Number 
(See 3GPP TS 
29.368 [15]) 


Reference- 
Number 


C 


This information element shall contain the Reference Number related to 
the device trigger request. 

It shall be present if it is available to the MTC-IWF, e.g. the MTC-IWF 
received this information over Tsp. 


Validity Period 
(See 3GPP TS 
29.368 [15]) 


Validity-Period 


C 


This information element shall contain the validity period of the device 
trigger request. 

It shall be present if it is available to the MTC-IWF, e.g. the MTC-IWF 
received this information over Tsp. 


Priority Indication 
(See 3GPP TS 
29.368 [15]) 


Priority- 
Indication 


C 


This information element shall contain the priority of the device trigger 

request.. 

It shall be present if it is available to the MTC-IWF, e.g. the MTC-IWF 

received this information over Tsp. 


SIVIS Application 
Port ID 

(See 3GPP TS 
29.368 [15]) 


SMS- 

Application- 

Port-ID 


C 


This information element shall contain the Application Port ID of the 
triggering application for the device trigger request. 
It shall be present if it is available to the MTC-IWF, e.g. the MTC-IWF 
received this information over Tsp. 


Supported 
Features 
(See 3GPP TS 
29.229 [6]) 


Supported- 
Features 





If present, this information element shall contain the list of features 
supported by the origin host. 
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Table 5.2.1.1/2: Device Trigger Answer 



Information 
Element Name 


IVIapping to 
Diameter AVP 


Cat. 


Description 


Result 
(See 7) 


Result-Code / 
Experimental- 
Result 


M 


This IE shall contain the result of the operation. 

The Result-Code AVP shall be used to indicate success / errors as 

defined in the Diameter Base Protocol. 

The Experimental-Result AVP shall be used for T4 errors. This is a 

grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id 

AVP, and the error code in the Experimental-Result-Code AVP. 

The following errors are applicable: 

Service Centre Congestion; 

Invalid Short IVIessage Entity Address; 

Subscriber not Service Centre Subscriber; 

SIVI Protocol Error. 


Supported 
Features 
(See 3GPP TS 
29.229 [6]) 


Supported- 
Features 





If present, this information element shall contain the list of features 
supported by the origin host. 



5.2.1.2 



Detailed Behaviour of the MTC-IWF 



The MTC-IWF shall make use of this procedure to transfer device trigger request received over Tsp interface from SCS 
to the SMS-SC. 

If the MTC-IWF retrieved the IMSI and serving node identities of the UE from the HSS, the MTC-IWF shall include 
these identities in the request to the SMS-SC. 

The MTC-IWF shall include the External Identifier of the UE if received over Tsp interface from SCS. 



5.2.1.3 



Detailed Behaviour of the SMS-SC 



When receiving a Device Trigger Request the SMS-SC shall check the identity of the UE received (i.e. IMSI or 
MSISDN) if it serves this UE. If not, a Result Code of DIAMETER_ERROR_USER_UNKNOWN shall be returned. 

If the SCS-Identity AVP contains an invahd SME address, the SMS-SC shall return a Resuh Code of 
DIAMETER_ERROR_INVALID_SME_ADDRESS. 

If the SMS-SC cannot fulfil the received request due to congestion, it shall return a Result Code of 
DIAMETER_ERROR_SC_CONGESTION. 

If there is an error with the protocol contained in the short message transfer protocol data unit, the SMS-SC shall return 
a Result Code of DIAMETER_ERROR_SM_PROTOCOL. 

If there are routing information (i.e. MSC or MME, SGSN, IP-SM-GW identities serving the UE for SMS) present in 
the request, the SMS-SC shall use the information for delivery of device trigger request for the UE. The SMS-SC shall 
return a Result Code of DIAMETER_SUCCESS to the MTC-IWF. 

NOTE: If the IP-SM-GW address is received, the SMS-SC uses the IP-SM-GW as the serving node with highest 
priority for delivery of device trigger request for the UE. 

If there is no routing information (i.e. MSC orMME, SGSN, IP-SM-GW identities serving the UE for SMS) present in 
the request, the SMS-SC shall send a Report-SM-Delivery-Status message to the HLR in order to update the MWD in 
the HLR (see 3GPP TS 23.040 [9]). 

If the SMS-SC cannot fulfil the received request, e.g. due to system failure, or congestion, it shall set Result-Code to 
DIAMETER UNABLE TO COMPLY. 
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5.2.2 Delivery Report of Device Trigger 



5.2.2.1 



General 



This procedure shall be used between the SMS-SC and the MTC-IWF for Delivery Report of Device Trigger. The 
procedure shall be invoked by the SMS-SC and is used: 

to report the success or failure of delivering the device trigger to the UE. 

This procedure is mapped to the commands Delivery-Report-Request/ Answer in the Diameter application specified in 
chapter 6. Tables 5.2.2.1/1 and 5.2.2.1/2 detail the involved information elements. 

Table 5.2.2.1/1: Delivery Report Request 



Information 
Element Name 


Mapping to 
Diameter AVP 


Cat. 


Description 


User Identifier 
(See 3GPP TS 
29.336 [12]) 


User-Identifier 


M 


This information element shall contain the IMSI of the UE the device 

trigger was delivered, formatted according to 3GPP TS 23.003 [8], clause 

2.2. 

This Information Element may contain the international ISDN number of 

the UE the device trigger was delivered, formatted according to 3GPP TS 

23.003 [8], clause 3.3. The ISDN number shall be present if it is available 

to the SMS-SC. 

This Information Element may contain the external identifier of the UE the 

device trigger was delivered, formatted according to 3GPP TS 23.003 [8], 

clause 19.7.2. The external identifier shall be present if it is available to 

the SMS-SC. 


SM RP OA 
(See 3GPP TS 
29.336 [12]) 


SCS-ldentity 


M 


This Information Element shall contain the identity of the Service 
Capability Server that is requesting a device trigger to the UE as received 
from the MTC-IWF. 


SIVI Delivery 
Outcome 
(See 6.3.1) 


SM-Delivery- 
Outcome 


M 


This information element shall be present and indicate one of the following 
outcomes of the device trigger delivery: 

Absent subscriber; 

UE memory capacity exceeded; 

Successful transfer. 


Absent 
Subscriber 
Diagnostic SM 
(See 6.3.2) 


Absent- 

Subscriber- 

Diagnostic-SM 


C 


This information element shall indicate the reason why the subscriber is 

absent. 

It shall be present if the device trigger failed to be delivered due to absent 

subscriber. 


Trigger 
Reference 
Number 
(See 3GPP TS 
29.368 [15]) 


Reference- 
Number 


C 


This information element shall contain the Trigger Reference Number as 

received from the MTC-IWF for the device trigger. 

This information element shall be present if it is available in the SMS-SC. 


Supported 
Features 
(See 3GPP TS 
29.229 [6]) 


Supported- 
Features 





If present, this information element shall contain the list of features 
supported by the origin host. 
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Table 5.2.2.1/2: Delivery Report Answer 



Information 
Element Name 


Mapping to 
Diameter AVP 


Cat. 


Description 


Result 
(See 7) 


Result-Code / 
Experimental- 
Result 


M 


This IE shall contain the result of the operation. 

The Result-Code AVP shall be used to indicate success / errors as 

defined in the Diameter Base Protocol. 

The Experimental-Result AVP shall be used for T4 errors. This is a 

grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id 

AVP, and the error code in the Experimental-Result-Code AVP. 


Supported 
Features 
(See 3GPP TS 
29.229 [6]) 


Supported-Features 





If present, this information element shall contain the list of features 
supported by the origin host. 



5.2.2.2 



Detailed Behaviour of the SMS-SC 



The SMS-SC shall make use of this procedure to report the success or failure of delivering the device trigger to the UE 
to the MTC-IWF. 

The SMS-SC shall include the identities of the UE, i.e. IMSI and/or MSISDN, the device trigger was delivered to. 

The SMS-SC shall include the External Identifier of the UE if the SMS-SC received it from MTC-IWF in the device 
trigger request message. 

The SMS-SC shall include an SCS-Identity AVP that contains the identity of the Service Capability Server that 
requested the device trigger to the UE as received from the MTC-IWF in the device trigger request message. 

The SMS-SC shall include an SM-Delivery-Outcome-T4 AVP that contains the outcome of the success or failure of 
delivering the device trigger to the UE. 

The SMS-SC shall include an Absent-Subscriber-Diagnostic-T4 AVP that contains the reason why the subscriber is 
absent if the device trigger failed to be delivered due to absent subscriber. 

5.2.2.3 Detailed Behaviour of the MTC-IWF 

The MTC-IWF shall return a Result Code of DIAMETER_SUCCESS to the SMS-SC. 



Protocol Specification and Implementation 



6.1 



General 



6.1 .1 Use of Diameter Base Protocol 

The Diameter Base Protocol as specified in IETF RFC 3588 [3] shall apply except as modified by the defined support 
of the methods and the defined support of the commands and AVPs, result and error codes as specified in this 
specification. Unless otherwise specified, the procedures (including error handling and unrecognised information 
handling) shall be used unmodified. 

6.1 .2 Securing Diameter Messages 

For secure transport of Diameter messages, see 3GPP TS 33.210 [4] 

6.1.3 Accounting Functionality 

Accounting functionality (Accounting Session State Machine, related command codes and AVPs) shall not be used on 
the T4 interface. 



£75/ 



3GPP TS 29.337 version 1 1 .2.0 Release 11 11 ETSI TS 1 29 337 V1 1 .2.0 (201 3-04) 

6.1.4 Use of Sessions 

Between the MTC-IWF and the SMS-SC, Diameter sessions shall be implicitly terminated. An implicitly terminated 
session is one for which the server does not maintain state information. The client shall not send any re-authorization or 
session termination requests to the server. 

The Diameter base protocol includes the Auth-Session-State AVP as the mechanism for the implementation of 
implicitly terminated sessions. 

The client (server) shall include in its requests (responses) the Auth-Session-State AVP set to the value 
NO_STATE_MAINTAINED (1), as described in IETF RFC 3588 [3]. As a consequence, the server shall not maintain 
any state information about this session and the client shall not send any session termination request. Neither the 
Authorization-Lifetime AVP nor the Session-Timeout AVP shall be present in requests or responses. 

6.1 .5 Transport Protocol 

Diameter messages over the T4 interface shall make use of SCTP, see IETF RFC 4960 [5]. 

6.1.6 Routing Considerations 

This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host. 

The T4 reference point is defined as an intra-operator interface, and both MTC-IWF and the SMS-SC are located in the 
same network domain. If the MTC-IWF knows the address/name of the SMS-SC for a certain user, both the 
Destination-Realm and Destination-Host AVPs shall be present in the request. Otherwise, the Destination-Realm AVP 
shall be present and the command shall be routed to the next Diameter node. Consequently, the Destination-Host AVP 
is declared as optional in the ABNF for all requests initiated by the MTC-IWF. 

The SMS-SC obtains the Destination-Host AVP to use in requests towards the MTC-IWF, from the Origin-Host AVP 
received in previous requests from the MTC-IWF. Consequently, the Destination-Host AVP is declared as mandatory in 
the ABNF for all requests initiated by the SMS-SC. 

If the Vendor-Specific- Application-ID AVP is received in any of the commands, it may be ignored by the receiving 
node, and it shall not be used for routing purposes. 

NOTE: The Vendor-Specific-Application-ID can be included as an optional AVP in all commands in order to 

ensure interoperability with diameter agents following a strict implementation of IETF RFC 3588 [3], by 
which messages not including this AVP will be rejected. IETF RFC 3588 [3] indicates that the AVP shall 
be present in all proxiable commands, such as those defined in this specification, despite the fact that the 
contents of this AVP are redundant since the Application ID is already present in the command header. 
This AVP may be removed in subsequent revisions of this specification, once the diameter base protocol 
is updated accordingly. 

6.1 .7 Advertising Application Support 

The MTC-IWF and SMS-SC shall advertise support of the Diameter T4 Application by including the value of the 
application identifier in the Auth- Application-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the 
Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. 

The vendor identifier value of 3GPP (10415) shall be included in the Supported- Vendor-Id AVP of the Capabilities- 
Exchange-Request and Capabilities-Exchange-Answer commands, and in the Vendor-Id AVP within the Vendor- 
Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer 
commands. 

The Vendor-Id AVP included in Capabilities-Exchange-Request and Capabilities-Exchange- Answer commands that is 
not included in the Vendor-Specific-Application-Id AVPs as described above shall indicate the manufacturer of the 
Diameter node as per IETF RFC 3588 [3]. 

6.1.8 Diameter Application Identifier 

The T4 interface protocol shall be defined as an IETF vendor specific Diameter application, where the vendor is 3GPP. 
The vendor identifier assigned by lANA to 3GPP (http://www.iana.org/assignments/enterprise-numbers) is 10415. 

The Diameter application identifier assigned to the T4 interface application is 167773 11 (allocated by lANA). 



£75/ 



3GPP TS 29.337 version 11.2.0 Release 11 



12 



ETSI TS 129 337 V1 1.2.0 (2013-04) 



6.1.9 Use of the Supported-Features AVP 



When new functionality is introduced on the T4 interface, it should be defined as optional. If backwards incompatible 
changes can not be avoided, the new functionality shall be introduced as a new feature and support advertised with the 
Supported-Features AVP. The usage of the Supported-Features AVP on the T4 interface is consistent with the 
procedures for the dynamic discovery of supported features as defined in clause 7.2 of 3GPP TS 29.229 [6]. 

When extending the application by adding new AVPs for a feature, the new AVPs shall have the M bit cleared and the 
AVP shall not be defined mandatory in the command ABNF. 

As defined in 3GPP TS 29.229 [6], the Supported-Features AVP is of type grouped and contains the Vendor-Id, 
Feature-List-ID and Feature-List AVPs. On the all reference points as specified in this specificaion, the Supported- 
Features AVP is used to identify features that have been defined by 3GPP and hence, for features defined in this 
document, the Vendor-Id AVP shall contain the vendor ID of 3GPP (10415). If there are multiple feature lists defined 
for the reference point, the Feature-List-ID AVP shall differentiate those lists from one another. 



6.2 



Commands 



6.2.1 Introduction 

This section defines the Command code values and related ABNF for each command described in this specification. 

6.2.2 Command-Code Values 

This section defines Command-Code values for the T4 interface application as allocated by lANA. 

Every command is defined by means of the ABNF syntax IETF RFC 5234 [10], according to the rules in IETF RFC 
3588 [3]. In the case, the definition and use of an AVP is not specified in this document, the guidelines in IETF RFC 
3588 [3] shall apply. 

The following Command Codes are defined in this specification: 

Table 7.2.2/1 : Command-Code values for T4 



Command-Name 


Abbreviation 


Code 


Section 


Device-Trigger-Request 


DTR 


8388643 


6.2.3 


Device-Trigger- Answer 


DTA 


8388643 


6.2.4 


Delivery-Report-Request 


DRR 


8388644 


6.2.5 


Delivery-Report-Answer 


DRA 


8388644 


6.2.6 



For these commands, the Application-ID field shall be set to 16777311 (application identifier of the T4 interface 
application, allocated by lANA). 

6.2.3 Device-Trigger-Request (DTR) Command 

The Device-Trigger-Request (DTR) command, indicated by the Command-Code field set to 8388643 and the "R" bit set 
in the Command Flags field, is sent from the MTC-IWF to the SMS-SC. 

Message Format 

< Device-Trigger-Request > ::=< Diameter Header: 8388643, REQ, PXY, 16777311 > 

< Session-Id > 
{ Auth-Session-State } 
{ Origin-Host } 
{ Origin-Realm } 
{ Destination-Host } 
{ Destination-Realm } 
{ User-Identifier } 
{ SCS -Identity } 
{ SM-RP-UI } 



£75/ 



3GPP TS 29.337 version 1 1 .2.0 Release 11 13 ETSI TS 1 29 337 V1 1 .2.0 (201 3-04) 

[ Serving-Node ] 

*[ Additional-Serving-Node ] 

[ Reference-Number ] 

[ Validity-Period ] 

[ Priority-Indication ] 

[ SMS-Application-Port-ID ] 

*[ Supported-Features ] 

*[ AVP ] 

*[ Proxy-Info ] 

*[ Route-Record ] 

6.2.4 Device-Trigger-Answer (DTA) Command 

The Device-Trigger-Answer (DTA) command, indicated by the Command-Code field set to 8388643 and the "R" bit 
cleared in the Command Flags field, is sent from the SMS-SC to the MTC-IWF. 

Message Format 

< Device-Trigger-Answer > ::= < Diameter Header: 8388643, PXY, 1677731 1 > 

< Session-Id > 

[ Vendor-Specific-Application-Id ] 

[ Result-Code ] 

[ Experimental-Result ] 

{ Auth-Session-State } 

{ Origin-Host } 

{ Origin-Realm } 

*[ Supported-Features ] 

*[ AVP ] 

*[ Failed- AVP ] 

*[ Proxy-Info ] 

*[ Route-Record ] 

6.2.5 Delivery-Report-Request (DRR) Command 

The Delivery-Report-Request (DRR) command, indicated by the Command-Code field set to 8388644 and the "R" bit 
set in the Command Flags field, is sent from the MTC-IWF to the SMS-SC. 

Message Format 

< Delivery-Report-Request > ::= < Diameter Header: 8388644, REQ, PXY, 1677731 1 > 

< Session-Id > 

{ Auth-Session-State } 

{ Origin-Host } 

{ Origin-Realm } 

{ Destination-Host } 

{ Destination-Realm } 

{ User-Identifier } 

{ SCS -Identity } 

{ SM-Delivery-Outcome-T4 } 

[ Absent-Subscriber-Diagnostic-T4 ] 

[ Reference-Number ] 

*[ Supported-Features ] 

*[ AVP ] 

*[ Proxy-Info ] 

*[ Route-Record ] 

6.2.6 Delivery-Report-Answer (DRA) Command 

The Delivery-Report-Answer (DRA) command, indicated by the Command-Code field set to 8388644 and the "R" bit 
cleared in the Command Flags field, is sent from the SMS-SC to the MTC-IWF. 

Message Format 
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< Delivery-Report-Answer > ::= < Diameter Header: 8388644, PXY, 1677731 1 > 

< Session-Id > 

[ Vendor-Specific-Application-Id ] 
[ Result-Code ] 
[ Experimental-Result ] 
{ Auth-Session-State } 
{ Origin-Host } 
{ Origin-Realm } 
*[ Supported-Features ] 
*[ AVP ] 
*[ Failed- AVP ] 
*[ Proxy-Info ] 
*[ Route-Record ] 



6.3 



AVPs 



The following table specifies the Diameter AVPs defined for the T4 interface protocol, their AVP Code values, types, 
possible flag values and whether or not the AVP may be encrypted. The Vendor-ID header of all AVPs defined in this 
specification shall be set to 3GPP (10415). 

Table 6.3.1/1 : T4 specific Diameter AVPs 





AVP Flag rules 




Attribute Name 


AVP Code 


Section 
defined 


Value Type 


Must 


May 


Should 
not 


Must 
not 


May 
Encr. 


SM-Delivery-Outcome-T4 


3200 


6.3.1 


Enumerated 


M, V 








No 


Absent-Subscriber-Diagnostic-T4 


3201 


6.3.2 


Enumerated 


M, V 








No 


NOTE 1 : The AVP header bit denoted as "M", indicates whether support of the AVP is required. The AVP header bit 
denoted as "V", indicates whether the optional Vendor-ID field is present in the AVP header. For further 
details, see IETF RFC 3588 [3]. 

NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M- 
bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the 
receiver understands the AVP but the IVI-bit value does not match with the definition in this table, the receiver 
shall ignore the IVI-bit. 



The following table specifies the Diameter AVPs re-used by the T4 interface protocol from existing Diameter 
Applications, including a reference to their respective specifications and when needed, a short description of their use 
within T4. 

Any other AVPs from existing Diameter Applications, except for the AVPs from Diameter Base Protocol, do not need 
to be supported. The AVPs from Diameter Base Protocol are not included in table 6.3.1/2, but they may be re-used for 
the T4 protocol. 
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Table 6.3.1/2: T4 re-used Diameter AVPs 



Attribute 
Name 


Reference 


Comments 


M-bit 


User- 
Identifier 


3GPPTS 29.336 [12] 






SCS- 
Identity 


3GPPTS 29.336 [12] 






SM-RP-UI 


3GPPTS 29.338 [13] 






Serving- 
Node 


3GPPTS 29.173 [14] 


See 6.3.3 




Additional- 

Serving- 

Node 


3GPPTS 29.173 [14] 


See 6.3.4 




Reference- 
Number 


3GPPTS 29.368 [15] 






Validity- 
Period 


3GPPTS 29.368 [15] 






Priority- 
Indication 


3GPPTS 29.368 [15] 






SMS- 

Application- 

Port-ID 


3GPPTS 29.368 [15] 






Supported- 
Features 


3GPP TS 29.229 [6] 






Feature- 
List-ID 


3GPP TS 29.229 [6] 






Feature- 
List 


3GPP TS 29.229 [6] 






IP-SM-GW- 
Name 


3GPPTS 29.336 [12] 






IP-SM-GW- 
Number 


3GPPTS 29.336 [12] 






MME- 
Number- 
for-MT- 
SMS 


3GPPTS 29.272 [18] 






NOTE 1 : The IVI-bit settings for re-used AVPs override those of the defining specifications that are referenced. Values 
include: "Must set", "Must not set". If the M-bit setting is blank, then the defining specification applies. 

NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M- 
bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the 
receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver 
shall ignore the M-bit. 



6.3.1 SM-Delivery-Outcome-T4 

The SM-Delivery-Outcome-T4 AVP is of type Enumerated and indicates the outcomes of the device trigger deHvery. 
The following values are defined: 

ABSENT_SUBSCRIBER (0) 
This value is used when the device trigger delivery failed due to absent subscriber. 

UE_MEMORTY_CAPACITY_EXCEEDED (1) 
This value is used when the device trigger delivery failed due to UE memory capacity exceeded. 

SUCCESSFUL_TRANSFER (2) 
This value is used when the device trigger delivery is successfully transferred to the UE. 



£75/ 



3GPP TS 29.337 version 1 1 .2.0 Release 11 16 ETSI TS 1 29 337 V1 1 .2.0 (201 3-04) 



6.3.2 Absent-Subscriber-Diagnostic-T4 



The Absent-Subscriber-Diagnostic -T4 AVP is of type Enumerated and indicates the reason why the subscriber is absent 
if the device trigger failed to be delivered due to absent subscriber. The following values are defined: 

NO_PAGING_RESPONSE (0) 
This value is used when there is no paging response via some of the serving nodes. 

UE_DET ACHED (1) 
This value is used when the UE is detached from all of the serving nodes. 

UE_DEREGISTERED (2) 
This value is used when the UE is deregistered in the network. 

UE_PURGED (3) 
This value is used when the UE is purged by some of the serving nodes. 

ROAMING_RESTRICTION (4) 
This value is used when the UE is roaming restricted. 

UNIDENTIFIED_SUBSCRIBER (5) 
This value is used when the user is unidentified in all of the serving nodes. 



6.3.3 Serving-Node 



The Serving-Node AVP is of type Grouped and it shall contain the name/number of the serving node to be used for T4- 
triggering. It is originally defined in 3GPP TS 29.173 [8]. 

Serving-Node ::=< AVP header: 2401 10415> 

[ SGSN-Number ] 

[ MME-Name ] 

[ MME-Realm ] 

[ MME-Number-for-MT-SMS ] 

[ MSC-Number ] 

[ IP-SM-GW-Number ] 

[ IP-SM-GW-Name ] 

*[AVP] 

The following combinations are allowed: 

a) SGSN-Number 

b) MME-Name & MME-Realm & MME-Number-for-MT-SMS 

c) MSC-Number 

d) MSC-Number & MME-Name & MME-Realm 

e) IP-SM-GW-Number 

f) IP-SM-GW-Number & IP-SM-GW-Name 
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6.3.4 Additional-Serving-Node 

The Additional Serving-Node AVP is of type Grouped and when present it shall contain the name/number of an 
additional serving node to be used for T4-triggering. It is originally defined in 3GPP TS 29.173 [8], 

Additional-Serving-Node ::= <AVP header: 2406 10415> 

[ SGSN-Number ] 

[ MME-Name ] 

[ MME-Realm ] 

[ MME-Number-for-MT-SMS ] 

[ MSC-Number ] 

*[AVP] 

The following combinations are allowed: 

a) SGSN-Number 

b) MME-Name & MME-Realm & MME-Number-for-MT-SMS 

c) MSC-Number 

d) MSC-Number & MME-Name & MME-Realm 

7 Result-Code and Experimental-Result Values 

7.1 General 

This section defines result code values that shall be supported by all Diameter implementations that conform to this 
specification. 

7.2 Success 

Result codes that fall within the Success category shall be used to inform a peer that a request has been successfully 
completed. The Result-Code AVP values defined in Diameter Base Protocol IETF RFC 3588 [3] shall be applied. 

7.3 Permanent Failures 

Errors that fall within the Permanent Failures category shall be used to inform the peer that the request has failed, and 
should not be attempted again. The Result-Code AVP values defined in Diameter Base Protocol IETF RFC 3588 [3] 
shall be applied. When one of the result codes defined here is included in a response, it shall be inside an Experimental- 
Result AVP and the Result-Code AVP shall be absent. 

7.3.1 DIAMETER_ERROR_USER_UNKNOWN (5001) 

This result code shall be sent by the SMS-SC to indicate that the user identified by the IMSI or the MSISDN is 
unknown. 

7.3.2 DIAMETER_ERRORJNVALID_SME_ADDRESS (5530) 

This result code shall be sent by the SMS-SC to indicate that the SME address is invalid. 



£75/ 



3GPP TS 29.337 version 1 1 .2.0 Release 11 18 ETSI TS 1 29 337 V1 1 .2.0 (201 3-04) 

7.3.3 DIAMETER_ERROR_SC_CONGESTION (5531 ) 

This result code shall be sent by the SMS-SC to indicate that SC is congested and unable to dehver the device trigger 
request. 

7.3.4 DIAMETER_ERROR_SM_PROTOCOL (5532) 

This result code shall be sent by the SMS-SC to indicate that there is an error with the protocol contained in the short 
message transfer protocol data unit. 
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